Remarks 



Applicants respectfully request reconsideration. To advance the prosecution of 
this application, Applicants have amended claims 1, 3, 9-11, 18-20, and 24, canceled 
claims 16-17, and submitted the following remarks. 

Claim Rejections: 35 U.S.C. §102 

The Examiner has rejected claim 21 under 35 U.S.C. § 102(e) as being 
anticipated by Shultz et al. (US Patent No. 7,269,482, hereinafter, "Shultz"). Applicants 
respectfully submit that this rejection is improper and should be withdrawn. 

Shultz is directed to a software framework 200 for managing the flow of digital 
information within a vehicle (Abstract). The system of Shultz includes integrated 
software applications 204 that communicate with a data warehouse 214. See Fig. 2. 
The data warehouse includes data sources 218. The data sources 218 can be either 
"sources" or "listeners." Col. 5, line 66 - col. 7, line 3. The "sources" are "locations in 
the data warehouse 214 to which an interface or application will took [sp.] to for data 
values for display or processing." Col. 5, lines 62-64. The "listeners" are "locations that 
applications or interfaces look to send values to based on conditions, triggers, or user 
actions." Col. 5, lines 64-66. 

The software applications 204 store and retrieve vehicle parameter data via the 
data sources 218 in the data warehouse 214. For example, "after a given value is 
stored in the data source 218, other applications can look-up the data source 218 and 
monitor any value changes in that data source." Col. 6, lines 36-38. The data 
warehouse 214 thus "provides an abstract interface for available vehicle data." Col. 5, 
lines 48-49. 

The use of the data warehouse does not explain how data is retrieved from 
devices over a vehicle data bus in the first instance. To address this need, Shultz 
includes a communications manager 21 2, which "provides an abstract interface 
between the framework 200 and devices and busses 206 that communicate with the 
framework." Col. 4, lines 46-48. The communications manager 212 is "responsible for 
[...] invoking low-level routines necessary to support specific communication protocols." 
Col. 4, lines 47-54. Shultz briefly discloses a process by which input-output device 
modules are "registered" with the software framework 200: 
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Registering input-output modules allow variation of bus message protocols, 
thereby allowing changes to the formats of messages to and from the vehicle bus 
108 without changing the definitions of corresponding data entries stored in the 
data warehouse 214. [col. 4, lines 57-62] 

The communications manager 212 therefore handles communication with devices over 
a vehicle's data bus, whereas the data warehouse 214 stores vehicle information that 
can be shared among different telematics applications. 

In contrast with Shultz, claim 21 is directed to a local data acquisition unit for 
installation within a vehicle. The unit includes, inter alia, a "telematics application" and 
an "abstract software layer," 

wherein the abstract software layer is constructed and arranged for 
extracting vehicle data from the proprietary vehicle data bus in response to the 
generic requests from the telematics application and for providing the extracted 
data to the telematics application. 

Although the communication manager 212 of Shultz appears to extract vehicle data 
from vehicle data busses, neither the communications manager 212 nor any other 
structure of Shultz extracts vehicle data from a proprietary vehicle data bus "in response 
to the generic requests from the telematics application." The communications manager 
212 and the data warehouse 214 operate independently. Telematics applications 
running on the framework of Shultz turn to the data sources 218 within the data 
warehouse 214 to access vehicle parameter data, not to the vehicle data bus itself. 
Vehicle data in Shultz are already stored in the data warehouse 214 when the 
telematics applications request them. There is no indication that the communications 
manager 212, the data warehouse 214, or any other structure in Shultz, reaches out to 
obtain vehicle data from a vehicle data bus specifically "in response to" a request from a 
telematics application. 

Therefore, Shultz does not disclose an abstract software layer "constructed and 
arranged for extracting vehicle data from the proprietary vehicle data bus in response to 
the generic requests from the telematics application," as required by claim 21 . 
Therefore, and for at least this reason, Shultz does not anticipate claim 21 , and the 
rejection of claim 21 under 35 U.S.C. § 102(e) is overcome. 

As claim 21 has not been rejected under any other grounds, Applicants 
respectfully submit that claim 21 is allowable. 
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The data acquisition unit recited in claim 21 has an advantage over the software 
framework of Shultz. Because Shultz relies on the data warehouse 214 as the central 
repository of vehicle data, it also carries the burden of ensuring that all data is kept up to 
date. For example, if a telematics application requests vehicle speed from the data 
warehouse, there is a risk that the value stored in the data warehouse will be stale and 
therefore an inaccurate reflection of the vehicle's current state. In contrast, with the 
data acquisition unit recited in claim 21 , vehicle data is obtained from the vehicle data 
bus as it is needed by the telematics application, effectively on demand. This 
arrangement inherently avoids stale data, and therefore promotes accuracy in the 
conduct of the telematics application. 

Claims 22 and 23 depend from claim 21. Claims 18-20 have been amended to 
depend from claim 21 . Therefore, claims 18-20 and 22-23 are also allowable. 

The Examiner has rejected claim 24 under 35 U.S.C. §1 02(e) as being 
anticipated by Shultz. Applicants have amended claim 24 and respectfully submit that 
claim 24 as amended is allowable. 

As an initial matter, Applicants have corrected claim 24 to change "creating a 
telematics application" to "providing a telematics application." This change is not related 
to the rejection but simply reflects the fact that the claim does not require a new 
telematics application to be created for each vehicle. 

Claim 24 as amended is directed to a method of deploying a telematics 
application in a plurality of vehicles having different makes and/or models, wherein an 
abstract software layer is installed within each of the plurality of vehicles and is 
operatively connected to a data bus of the respective vehicle. The method includes, 
inter alia, the steps of 

providing a telematics application that includes generic requests to the 
abstract software layer for vehicle data; [ ... and] 

accessing, by the abstract software layer and responsive to the generic 
requests by the telematics application, vehicle data specified in the telematics 
application from the respective vehicle's data bus[.] 

Shultz does not disclose all the steps of claim 24 as amended. For example, 
Shultz does not disclose the "accessing" step included above. As already stated, 
telematics applications running in the Shultz framework access vehicle data from a data 
warehouse 214, not from the vehicle data bus. In addition, no structure in Shultz is 
arranged for accessing vehicle data from the respective vehicle's data bus "responsive 
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to the generic requests by the telematics application," as required by claim 24 as 
amended. Telematics applications in Shultz can store and retrieve vehicle data from 
various data sources 218 in the data warehouse 214, but nothing suggests that 
telematics applications can directly cause data to be accessed from a vehicle data bus. 
Therefore, Shultz does not disclose "accessing, by the abstract software layer and 
responsive to the generic requests by the telematics application, vehicle data specified 
in the telematics application from the respective vehicle's data bus," as recited in claim 
24 as amended. 

Therefore, and for at least this reason, Shultz does not anticipate claim 24 as 
amended. Therefore, the rejection of claim 24 as amended is overcome. As claim 24 
as amended has not been rejected under any other grounds, Applicants respectfully 
submit that claim 24 as amended is allowable. 

Claim Rejections: 35 U.S.C. § 103 

The Examiner has rejected claim 1 under 35 U.S.C. § 103(a) as being obvious 
based on Shultz in view of Seashore. (US Patent No. 5,916,286). Applicants have 
amended claim 1 and respectfully submit that claim 1 as amended is allowable. 

The instant amendments were not required to overcome the rejection, however, 
as the Office Action did not make a prima facie case for rejecting claim 1 . Claim 1 as 
previously presented recited, inter alia, the following steps, which the Office Action did 
not address: 

extracting vehicle data from the vehicle data bus using the vehicle data 
bus information retrieved from the database, the vehicle data corresponding to 
the request for vehicle parameter data; 

interpreting the retrieved vehicle data; and 

providing the interpreted data to the telematics application to satisfy the 
request for vehicle data. 

The Office Action made no assertion that any of the above-recited steps can be found in 
either of the cited references. Therefore, the rejection did not address all elements of 
claim 1, and the rejection of claim 1 under 35 U.S.C. §1 03(a) should be withdrawn. 

Applicants have amended claim 1 to improve its clarity, by replacing the term 
"vehicle data" with the term "vehicle parameter data" and by replacing the term "data 
bus information" with the term "data bus configuration information." As used throughout 
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the claims, the term, "vehicle parameter data," refers to the actual content of vehicle 
information conveyed over a vehicle data bus, such as engine speed, for example. See 
T(29 of the specification. It does not refer to the format or protocol of the data bus itself. 
In contrast, the term "data bus configuration information" refers to information pertaining 
to a particular vehicle data bus. It includes, for example, 

the data protocol type, the access method for the parameter, value addresses, 
shift and mask information, return value decoding methods, scaling and unit 
conversion, etc. [\27\ 

In simple terms, "vehicle parameter data" specifies information about a vehicle, whereas 
"data bus configuration information" specifies information about a data bus. 

With this distinction in mind, it is seen that claim 1 as amended is directed to a 
method of acquiring vehicle parameter data from a vehicle data bus. The recited 
method includes a step of 

retrieving, by the abstract software layer and responsive to a request for 
vehicle parameter data from the telematics application, vehicle data bus 
configuration information from a database [... , emphasis added]. 

The Examiner has asserted that Shultz teaches "retrieving, by the abstract 
software layer and responsive to a request for vehicle parameter data from the 
telematics application, vehicle data bus information from a database." See page 5, ^5 
of the Detailed Action. However, Shultz does not disclose "retrieving [. . .] vehicle data 
bus configuration information," as recited in claim 1 as amended. Shultz does state that 
the communications manager 212 handles communications over a vehicle data bus, but 
there is no discussion about the retrieval of vehicle data bus configuration information 
itself. Neither does Shultz disclose "retrieving" vehicle data bus configuration 
information "responsive to a request for vehicle parameter data," as required by claim 1 
as amended. In Shultz, vehicle parameter data has already been provided to the data 
warehouse 214 by the time a telematics application requests it. Data bus configuration 
information is therefore not relevant to the process used in Shultz tor requesting vehicle 
parameter data. Therefore, Shultz does not disclose the "retrieving" step as recited in 
claim 1 as amended. 

An essential difference between Shultz and the method recited in claim 1 as 
amended is that telematics applications in Shultz do not access the vehicle data bus to 
retrieve vehicle parameter data. Instead, they access the data warehouse 212, where 
vehicle parameter data has previously been stored. 
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The Examiner has acknowledged that Shultz does not disclose 

retrieving [...] vehicle data bus information from a database that stores 
data bus information for a plurality of different types of data busses, the retrieved 
vehicle data bus information being associated with the type of data bus used on 
the vehicle on which the telematics application is executed." [page 5, last 
paragraph of the Detailed Action]. 

In an effort to meet this aspect of the claim, the Examiner refers to Seashore. 

Seashore appears to teach a method of allowing a user to select between 
different data bus codes for pre-configuring a portable diagnostic tool for use with a 
desired vehicle make (see Abstract and Fig. 4). The user performs this pre- 
configuration before any application program seeks to acquire data from a vehicle. 

In contrast with Shultz and Seashore, claim 1 as amended recites a step of 

retrieving, by the abstract software layer and responsive to a request for 
vehicle parameter data from the telematics application, vehicle data bus 
configuration information from a database that stores data bus configuration 
information for a plurality of different types of data busses, the retrieved vehicle 
data bus configuration information being associated with the type of data bus 
used on the vehicle on which the telematics application is executed [emphasis 
added]. 

There is no basis in Shultz for an abstract software layer retrieving "data bus 
configuration information" "responsive to a request for vehicle parameter data from the 
telematics application," as recited in claim 1 as amended. In response to a request from 
a telematics application, Shultz accesses the data warehouse 212. It does not retrieve 
data bus configuration information or access a vehicle data bus. The fact that Seashore 
provides a way of storing different codes for different vehicle types is therefore 
irrelevant. The system of Shultz would not use them "responsive to a request for 
vehicle parameter data from the telematics application" since it does not, and has no 
reason to, access the vehicle data bus. Therefore, the combination of Shultz with 
Seashore fails to meet the "retrieving" step of claim 1 as amended. 

For at least the reasons set forth above, Applicants respectfully submit that claim 
1 as amended is allowable. 

Claim 3 has been amended to bring its language into accord with that of claim 1 
as amended. 

Claims 2, 3 as amended, 4, and 14 depend from claim 1 as amended. 
Therefore, claims 2, 3 as amended, 4, and 14 are also allowable. 



7 



The Examiner has rejected claim 9 under 35 U.S.C. § 103(a) as being obvious 
based on Klausner (US Patent No. 6,748,305) in view of Seashore. Applicants have 
amended claim 9 and respectfully submit that claim 9 as amended is allowable. 

Applicants have amended claim 9 to improve clarity. As with claim 1 as 
amended, the term "vehicle data" has been replaced with the term "vehicle parameter 
data" and the term "data bus information" has been replaced with the term "data bus 
configuration information." 

With the distinction between these terms in mind, it is seen that claim 9 as 
amended is directed to a method of acquiring vehicle parameter data from any of a 
plurality of different vehicle makes. The recited method includes, inter alia, the steps of 

requesting vehicle parameter data by the telematics application; [and] 

accessing, responsive to the step of requesting vehicle parameter data, a 
database that stores data bus configuration information for a plurality of different 
vehicle makes [emphasis added]. 

Claim 9 as amended is therefore seen to involve both "vehicle parameter data" and 
"data bus configuration information" A telematics application performs a step of 
"requesting vehicle parameter data," i.e., information about the vehicle, such as engine 
speed. Responsive to this step of "requesting," a step is performed of "accessing [...] a 
database that stores data bus configuration information [...]," i.e., information about the 
data bus of the vehicle. 

To obtain the "data bus configuration information," claim 9 as amended recites a 
step of 

querying the database to retrieve data bus configuration information for a 
particular vehicle make that corresponds to the vehicle [.] 

Prior to Applicants' amendments herein, the Examiner has asserted that Klausner 
disclosed the "querying" step (see the paragraph bridging pages 8 and 9 of the Detailed 
Action). However, it is clear that Klausner does not disclose a step of "querying the 
database to retrieve data bus configuration information," as recited in claim 9 as 
amended. The portions of Klausner that the Examiner alleged to disclose the "querying" 
step relate to "vehicle parameter data" only (Col. 2, lines 34-38). There is no mention of 
anything resembling "data bus configuration information." Indeed, Klausner does not 
address the problem of handling different data bus configurations or protocols for 
different vehicle makes. Therefore, "data bus configuration information," and the 
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"querying" step in general, are irrelevant to Klausner. Therefore, Klausner does not 
disclose a step of "querying the database to retrieve data bus configuration information 
for a particular vehicle make that corresponds to the vehicle," as recited in claim 9 as 
amended. 

Claim 9 as amended further recites a step of 

extracting vehicle parameter data from a vehicle data bus using the 
vehicle data bus configuration information [emphasis added]. 

The Examiner has asserted that Klausner disclosed the "extracting" step {Id.). 
However, Klausner clearly does not disclose a step of "extracting vehicle parameter 
data using the data bus configuration information," as recited in claim 9 as amended. 
Since Klausner does not employ "data bus configuration information," there is no way it 
can use that information for "extracting vehicle parameter data," as required by claim 9 
as amended. Therefore, Klausner does not disclose a step of "extracting vehicle 
parameter data from a vehicle data bus using the vehicle data bus configuration 
information," as required by claim 9 as amended. 

In addition, claim 9 as amended recites a step of 

conditionally requesting other vehicle parameter data by the telematics 
application depending upon the extracted vehicle parameter data. 

The Examiner has asserted that Klausner inherently discloses this step. However, this 
assertion was based on the contention that Klausner disclosed the "querying" and 
"extracting" steps. As Applicants have pointed out, however, Klausner does not 
disclose either the "querying" step or the "extracting" step as recited in claim 9 as 
amended. Therefore, it does not follow that Klausner inherently discloses the 
"conditionally requesting" step above. To the contrary, nothing in Klausner teaches that 
a telematics application ever requests vehicle parameter data in response to other, 
previously extracted vehicle parameter data. Therefore, Klausner does not disclose a 
step of "conditionally requesting other vehicle parameter data by the telematics 
application depending upon the extracted vehicle parameter data," as recited in claim 9 
as amended. 

Therefore, the grounds for rejecting claim 9 as amended have been overcome, 
Therefore, and for at least these reasons, the rejection of claim 9 as amended under 35 
U.S.C. § 103(a) should be withdrawn. Applicants respectfully submit that claim 9 as 
amended is allowable. 
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Claims 10 and 1 1 have been amended to use language consistent with that of 
claim 9 as amended. 

Claims 10 and 11, as amended, and claims 12-13 and 15 depend from claim 9 
as amended and are allowable for the same reasons. 

Conclusion: 

Applicants contend that the application is now in condition for allowance. A 
notice to that effect is earnestly solicited. If, after reviewing this response, the Examiner 
believes that any of the claims of this application are still not allowable, the Examiner is 
invited to call Applicants' attorney at the telephone number below. 



Respectfully Submitted, 

/Bruce D. Rubenstein #39,349/ 

Bruce D. Rubenstein 
Reg. No. 39,349 
Attorney for Applicants 



Atty. Docket :TERAD-11-US 
Telephone : 781-274-0202 
Fax : 781-274-0201 



10 



